🚑 Scaling fetching datta from gdrive #710
Conversation
|
Qovery can create a Preview Environment for this PR.
This comment has been generated from Qovery AI 🤖.
|
|
|
|
|
Caution Review failedThe pull request is closed. 📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces several changes to the queue management and data ingestion processes within the application. A new queue for third-party data ingestion is added, along with corresponding updates to the service and type definitions to accommodate this functionality. Modifications to the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GoogleDriveService
participant GoogleDriveQueueProcessor
participant BullQueueService
User->>BullQueueService: Add job to Queues.THIRD_PARTY_DATA_INGESTION
BullQueueService->>GoogleDriveQueueProcessor: Process job
GoogleDriveQueueProcessor->>GoogleDriveService: handleGoogleDriveSync(job)
GoogleDriveService->>GoogleDriveService: ingestData(sourceData, connectionId, customFieldMappings, extraParams)
GoogleDriveService-->>GoogleDriveQueueProcessor: Return processed data
GoogleDriveQueueProcessor-->>BullQueueService: Job completed
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Security
Changes Detected
|
Security
Changes Detected
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
🧹 Outside diff range comments (1)
packages/api/src/@core/@core-services/unification/ingest-data.service.ts (1)
Line range hint
1-324: Summary of changes and recommendationsThe modifications to
IngestDataServiceappear to be part of a larger refactoring effort to enhance the data ingestion process. Key points to address:
- Optimize the creation of
ingestParamsfor better performance.- Clarify the new data ingestion strategy, given the removal of the direct
ingestDatacall.- Consider removing commented-out code if it's no longer needed.
These changes have the potential to improve the overall efficiency and maintainability of the service. Please review the specific comments for detailed recommendations and ensure that the new data flow is well-documented for future maintenance.
🧰 Tools
🪛 Biome
[error] 90-90: Avoid the use of spread (
...) syntax on accumulators.Spread syntax should be avoided on accumulators (like those in
.reduce) because it causes a time complexity ofO(n^2).
Consider methods such as .splice or .push instead.(lint/performance/noAccumulatingSpread)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (9)
- packages/api/src/@core/@core-services/queues/queue.module.ts (1 hunks)
- packages/api/src/@core/@core-services/queues/shared.service.ts (2 hunks)
- packages/api/src/@core/@core-services/queues/types.ts (1 hunks)
- packages/api/src/@core/@core-services/unification/ingest-data.service.ts (3 hunks)
- packages/api/src/@core/utils/helpers.ts (1 hunks)
- packages/api/src/@core/utils/types/interface.ts (1 hunks)
- packages/api/src/filestorage/file/services/googledrive/index.ts (2 hunks)
- packages/api/src/filestorage/file/services/googledrive/processor.ts (1 hunks)
- packages/api/src/main.ts (1 hunks)
🧰 Additional context used
🪛 Biome
packages/api/src/@core/@core-services/unification/ingest-data.service.ts
[error] 90-90: Avoid the use of spread (
...) syntax on accumulators.Spread syntax should be avoided on accumulators (like those in
.reduce) because it causes a time complexity ofO(n^2).
Consider methods such as .splice or .push instead.(lint/performance/noAccumulatingSpread)
packages/api/src/filestorage/file/services/googledrive/index.ts
[error] 31-31: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
[error] 151-151: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 152-152: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 153-153: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 154-154: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 155-155: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
🔇 Additional comments (10)
packages/api/src/filestorage/file/services/googledrive/processor.ts (3)
7-9: LGTM! Class declaration and decorators are well-structured.The class declaration and decorators are correctly implemented:
@Injectable()is properly used for dependency injection in NestJS.@Processor(Queues.THIRD_PARTY_DATA_INGESTION)correctly specifies the queue this processor will handle.- The class name
GoogleDriveQueueProcessoris descriptive and follows PascalCase convention.
10-10: LGTM! Constructor follows dependency injection best practices.The constructor is well-implemented:
- It correctly injects an instance of
GoogleDriveService.- The use of
private readonlyensures the service cannot be modified after initialization, promoting immutability.
1-23: Overall, the implementation is solid. Verify integration with the broader system.The
GoogleDriveQueueProcessoris well-implemented, following NestJS and Bull best practices. It correctly sets up a processor for handling Google Drive synchronization jobs.To ensure full functionality:
Verify that this processor is properly registered in the module. Run the following command to check the module file:
This will search for references to
GoogleDriveQueueProcessorin files named "module.ts" within the file storage context. Ensure it's included in theprovidersarray of the relevant module.packages/api/src/@core/@core-services/queues/shared.service.ts (2)
40-42: LGTM! The new getter method is well-implemented.The
getThirdPartyDataIngestionQueue()method is correctly implemented and follows the existing patterns in the class. It provides a clean way to access thethirdPartyDataIngestionQueueproperty.
17-18: Verify the usage of the new queue and getter method.The new
thirdPartyDataIngestionQueueand its getter methodgetThirdPartyDataIngestionQueue()have been correctly implemented. To ensure these changes are fully integrated:
- Verify that
Queues.THIRD_PARTY_DATA_INGESTIONis properly defined in theQueuesenum.- Check if the new queue and getter method are being used appropriately in other parts of the codebase.
Run the following script to verify the integration:
This script will help ensure that the new queue is properly defined and used throughout the codebase.
Also applies to: 40-42
✅ Verification successful
Verification Successful: The new queue and getter method are properly integrated.
THIRD_PARTY_DATA_INGESTIONis defined in theQueuesenum.thirdPartyDataIngestionQueueis declared and used withinshared.service.ts.getThirdPartyDataIngestionQueue()method is implemented and utilized ingoogledrive/index.ts.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of the new third-party data ingestion queue # Test 1: Check if THIRD_PARTY_DATA_INGESTION is defined in Queues enum echo "Checking Queues enum definition:" rg --type typescript "enum\s+Queues" -A 10 | rg "THIRD_PARTY_DATA_INGESTION" # Test 2: Search for usage of thirdPartyDataIngestionQueue echo "\nChecking usage of thirdPartyDataIngestionQueue:" rg --type typescript "thirdPartyDataIngestionQueue" # Test 3: Search for usage of getThirdPartyDataIngestionQueue method echo "\nChecking usage of getThirdPartyDataIngestionQueue method:" rg --type typescript "getThirdPartyDataIngestionQueue\(\)"Length of output: 607
Script:
#!/bin/bash # Description: Verify the integration of the new third-party data ingestion queue # Test 1: Check if THIRD_PARTY_DATA_INGESTION is defined in Queues enum echo "Checking Queues enum definition:" rg --type ts "enum\s+Queues" -A 10 | rg "THIRD_PARTY_DATA_INGESTION" # Test 2: Search for usage of thirdPartyDataIngestionQueue echo "\nChecking usage of thirdPartyDataIngestionQueue:" rg --type ts "thirdPartyDataIngestionQueue" # Test 3: Search for usage of getThirdPartyDataIngestionQueue method echo "\nChecking usage of getThirdPartyDataIngestionQueue method:" rg --type ts "getThirdPartyDataIngestionQueue\(\)"Length of output: 1030
packages/api/src/@core/utils/types/interface.ts (1)
Line range hint
1-88: Final thoughts and verification stepThe changes to this file enhance the flexibility of data synchronization and ingestion, which aligns well with the PR's objective of scaling data fetching from Google Drive. The additions to
SyncParamandIBaseObjectServiceprovide a good foundation for handling custom field mappings and additional parameters during the ingestion process.To ensure these changes are properly integrated and don't introduce any breaking changes, please run the following verification script:
This script will help identify any areas of the codebase that might need updates to accommodate these new changes, as well as any remaining tasks related to the implementation.
packages/api/src/main.ts (1)
98-98:⚠️ Potential issueClarify the impact and plans for the commented-out
generatePanoraParamsSpeccall.The
generatePanoraParamsSpec(document)call has been commented out and replaced with a TODO comment. This change could potentially affect the completeness of the API documentation. Please address the following points:
- What is the impact of removing this function call? Are there any parts of the API documentation that will be missing or incomplete as a result?
- Why was this change made? Is there a specific issue that necessitated commenting out this line?
- What are the plans to address this TODO? Is there a timeline for re-implementing or replacing this functionality?
To help assess the impact, let's check for any references to
generatePanoraParamsSpecin the codebase:To ensure this TODO is not forgotten, consider creating a JIRA ticket or GitHub issue to track this task. This will help maintain visibility on this pending work and ensure it's addressed in future development cycles.
✅ Verification successful
Verify the impact of commenting out
generatePanoraParamsSpecThe
generatePanoraParamsSpec(document)call has been commented out inpackages/api/src/main.tsand is not referenced elsewhere in the codebase. This change may lead to incomplete API documentation generation. Please ensure that:
- The TODO is tracked in your issue management system to address re-enabling or replacing this functionality in the future.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for references to generatePanoraParamsSpec rg "generatePanoraParamsSpec" --type tsLength of output: 325
packages/api/src/@core/@core-services/unification/ingest-data.service.ts (2)
96-97: LGTM: Proper inclusion ofingestParamsinsyncParam.The addition of
ingestParamsto thesyncParamobject ensures that the filtered and processed parameters are correctly passed to the sync operation. This change is consistent with the introduction ofingestParamsand improves the flexibility of the sync process.
Line range hint
133-143: Clarify the removal of directingestDatacall and update comments.The commented-out code block removes the direct call to
ingestDataafter the sync operation. This change suggests a potential shift in the data ingestion strategy.Please clarify:
- Has the data ingestion process been moved to a different part of the application?
- If so, where is it now handled?
- If this code is no longer needed, consider removing it entirely rather than leaving it commented out.
To help verify the current usage of
ingestData, you can run the following script:This will help identify if and where the
ingestDatamethod is now being called, providing context for the removed code.✅ Verification successful
Remove the commented-out
ingestDatacode block.The
ingestDatamethod is still utilized in other parts of the codebase:
packages/api/src/filestorage/file/services/googledrive/index.tspackages/api/src/@core/utils/types/interface.tsSince data ingestion is handled elsewhere, the commented-out code in
ingest-data.service.tsis unnecessary and should be removed to enhance code clarity and maintainability.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for calls to ingestData method rg "ingestData\(" --type typescriptLength of output: 72
Script:
#!/bin/bash # Search for calls to ingestData method using the correct TypeScript file type rg "ingestData\(" --type tsLength of output: 266
packages/api/src/filestorage/file/services/googledrive/index.ts (1)
93-105: Ensure proper pagination and processing of all filesThe current implementation schedules jobs for processing batches but may miss processing the last page if
nextPageTokenis not properly handled.Run the following script to check whether all pages are being processed:
Ensure that
SCHEDULED_JOBSmatchesEXPECTED_PAGES.
| export function sleep(ms: number): Promise<void> { | ||
| return new Promise((resolve) => setTimeout(resolve, ms)); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Consider adding a brief JSDoc comment.
The sleep function is well-implemented and follows good practices. It provides a useful utility for introducing delays in asynchronous operations, which could be beneficial for rate limiting or managing API requests when fetching data from Google Drive.
Consider adding a brief JSDoc comment to improve documentation:
+/**
+ * Pauses execution for the specified number of milliseconds.
+ * @param ms The number of milliseconds to sleep.
+ * @returns A Promise that resolves after the specified delay.
+ */
export function sleep(ms: number): Promise<void> {
return new Promise((resolve) => setTimeout(resolve, ms));
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export function sleep(ms: number): Promise<void> { | |
| return new Promise((resolve) => setTimeout(resolve, ms)); | |
| } | |
| /** | |
| * Pauses execution for the specified number of milliseconds. | |
| * @param ms The number of milliseconds to sleep. | |
| * @returns A Promise that resolves after the specified delay. | |
| */ | |
| export function sleep(ms: number): Promise<void> { | |
| return new Promise((resolve) => setTimeout(resolve, ms)); | |
| } |
| @@ -4,4 +4,5 @@ export enum Queues { | |||
| SYNC_JOBS_WORKER = 'SYNC_JOBS_WORKER', // Queue which syncs data from remote 3rd parties | |||
| FAILED_PASSTHROUGH_REQUESTS_HANDLER = 'FAILED_PASSTHROUGH_REQUESTS_HANDLER', // Queue which handles failed passthrough request due to rate limit and retries it with backOff | |||
| RAG_DOCUMENT_PROCESSING = 'RAG_DOCUMENT_PROCESSING', | |||
| THIRD_PARTY_DATA_INGESTION = 'THIRD_PARTY_DATA_INGESTION', | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Consider adding a descriptive comment.
The addition of THIRD_PARTY_DATA_INGESTION to the Queues enum is appropriate and aligns with the PR's objective of scaling data fetching from Google Drive. The naming convention is consistent with other entries.
Consider adding a descriptive comment for this new queue type, similar to the other entries. For example:
- THIRD_PARTY_DATA_INGESTION = 'THIRD_PARTY_DATA_INGESTION',
+ THIRD_PARTY_DATA_INGESTION = 'THIRD_PARTY_DATA_INGESTION', // Queue for ingesting data from third-party sources like Google Drive📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| THIRD_PARTY_DATA_INGESTION = 'THIRD_PARTY_DATA_INGESTION', | |
| THIRD_PARTY_DATA_INGESTION = 'THIRD_PARTY_DATA_INGESTION', // Queue for ingesting data from third-party sources like Google Drive |
| { | ||
| name: Queues.THIRD_PARTY_DATA_INGESTION, | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Consider adding a comment for the new queue.
The addition of the THIRD_PARTY_DATA_INGESTION queue is correct and aligns with the PR objective of scaling data fetching from Google Drive. The implementation is consistent with the existing code structure.
Consider adding a brief comment above this queue configuration to explain its purpose, similar to:
// Queue for handling third-party data ingestion tasks, such as fetching data from Google Drive
{
name: Queues.THIRD_PARTY_DATA_INGESTION,
},This would improve code readability and make it easier for other developers to understand the purpose of this queue.
| import { Process, Processor } from '@nestjs/bull'; | ||
| import { Injectable } from '@nestjs/common'; | ||
| import { Job } from 'bull'; | ||
| import { Queues } from '@@core/@core-services/queues/types'; | ||
| import { GoogleDriveService } from '.'; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Consider using named imports for clarity.
The imports are appropriate for a NestJS application using Bull for queue processing. However, for better clarity and maintainability, consider using named imports for the Queues type.
Apply this change to improve import clarity:
-import { Queues } from '@@core/@core-services/queues/types';
+import { Queues } from '@@core/@core-services/queues/types';Committable suggestion was skipped due to low confidence.
| @Process('fs_file_googledrive') | ||
| async handleGoogleDriveSync(job: Job) { | ||
| try { | ||
| await this.googleDriveService.processBatch(job); | ||
| } catch (error) { | ||
| console.error( | ||
| `Failed to process Google Drive sync job: ${error.message}`, | ||
| ); | ||
| throw error; | ||
| } | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Consider enhancing error logging for better debugging.
The handleGoogleDriveSync method is well-implemented:
- The
@Process('fs_file_googledrive')decorator correctly specifies the job type. - The method is properly declared as async and takes a
Jobparameter. - Error handling is implemented with a try-catch block.
However, there's room for improvement in error logging:
Consider enhancing the error logging to include more context:
} catch (error) {
console.error(
- `Failed to process Google Drive sync job: ${error.message}`,
+ `Failed to process Google Drive sync job: ${error.message}`,
+ `Job ID: ${job.id}, Data: ${JSON.stringify(job.data)}`,
+ error.stack
);
throw error;
}This change will provide more context for debugging, including the job ID and data.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Process('fs_file_googledrive') | |
| async handleGoogleDriveSync(job: Job) { | |
| try { | |
| await this.googleDriveService.processBatch(job); | |
| } catch (error) { | |
| console.error( | |
| `Failed to process Google Drive sync job: ${error.message}`, | |
| ); | |
| throw error; | |
| } | |
| } | |
| @Process('fs_file_googledrive') | |
| async handleGoogleDriveSync(job: Job) { | |
| try { | |
| await this.googleDriveService.processBatch(job); | |
| } catch (error) { | |
| console.error( | |
| `Failed to process Google Drive sync job: ${error.message}`, | |
| `Job ID: ${job.id}, Data: ${JSON.stringify(job.data)}`, | |
| error.stack | |
| ); | |
| throw error; | |
| } | |
| } |
| async processBatch(job: any) { | ||
| const { | ||
| linkedUserId, | ||
| query, | ||
| pageToken, | ||
| connectionId, | ||
| custom_field_mappings, | ||
| ingestParams, | ||
| } = job.data; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Define a specific type for the job parameter in processBatch
Using any for the job parameter reduces type safety and may introduce runtime errors. Defining a specific type enhances maintainability and readability.
Consider defining an interface for the job data:
interface GoogleDriveJobData {
linkedUserId: string;
query: string;
pageToken?: string;
connectionId: string;
custom_field_mappings?: { slug: string; remote_id: string }[];
ingestParams?: { [key: string]: any };
}Then update the method signature:
- async processBatch(job: any) {
+ async processBatch(job: { data: GoogleDriveJobData }) {| private async getLastSyncTime(connectionId: string): Promise<Date | null> { | ||
| const lastSync = await this.prisma.fs_files.findFirst({ | ||
| where: { id_connection: connectionId }, | ||
| orderBy: { modified_at: 'desc' }, | ||
| }); | ||
| return lastSync ? lastSync.modified_at : null; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Optimize getLastSyncTime query performance
Retrieving the latest modified time without proper indexing can lead to performance issues on large datasets.
Ensure that there's an index on id_connection and modified_at fields in the fs_files table to optimize the query.
Consider updating the database schema to include the necessary indexes.
| @Injectable() | ||
| export class GoogleDriveService implements IFileService { | ||
| constructor( | ||
| private prisma: PrismaService, | ||
| private logger: LoggerService, | ||
| private cryptoService: EncryptionService, | ||
| private registry: ServiceRegistry, | ||
| private ingestService: IngestDataService, | ||
| private bullQueueService: BullQueueService, | ||
| ) { | ||
| this.logger.setContext( | ||
| FileStorageObject.file.toUpperCase() + ':' + GoogleDriveService.name, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use template literals instead of string concatenation
The current string concatenation can be replaced with a template literal for improved readability and consistency.
Apply this diff to update the code:
- this.logger.setContext(
- FileStorageObject.file.toUpperCase() + ':' + GoogleDriveService.name,
- );
+ this.logger.setContext(
+ `${FileStorageObject.file.toUpperCase()}:${GoogleDriveService.name}`,
+ );📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| FileStorageObject.file.toUpperCase() + ':' + GoogleDriveService.name, | |
| `${FileStorageObject.file.toUpperCase()}:${GoogleDriveService.name}`, |
🧰 Tools
🪛 Biome
[error] 31-31: Template literals are preferred over string concatenation.
Unsafe fix: Use a template literal.
(lint/style/useTemplate)
| id: file.id!, | ||
| name: file.name!, | ||
| mimeType: file.mimeType!, | ||
| modifiedTime: file.modifiedTime!, | ||
| size: file.size!, |
There was a problem hiding this comment.
Avoid using non-null assertions
Using the non-null assertion operator ! can lead to runtime errors if any of the properties are null or undefined. It's safer to handle possible undefined values appropriately.
Consider handling the potential undefined values or ensuring that these properties are always defined before usage. You can use optional chaining or provide default values.
Apply this diff to remove the non-null assertions and handle potential undefined values:
- id: file.id!,
+ id: file.id ?? '',
- name: file.name!,
+ name: file.name ?? '',
- mimeType: file.mimeType!,
+ mimeType: file.mimeType ?? '',
- modifiedTime: file.modifiedTime!,
+ modifiedTime: file.modifiedTime ?? '',
- size: file.size!,
+ size: file.size ?? '0',📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| id: file.id!, | |
| name: file.name!, | |
| mimeType: file.mimeType!, | |
| modifiedTime: file.modifiedTime!, | |
| size: file.size!, | |
| id: file.id ?? '', | |
| name: file.name ?? '', | |
| mimeType: file.mimeType ?? '', | |
| modifiedTime: file.modifiedTime ?? '', | |
| size: file.size ?? '0', |
🧰 Tools
🪛 Biome
[error] 151-151: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 152-152: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 153-153: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 154-154: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 155-155: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
| private async rateLimitedRequest<T>(request: () => Promise<T>): Promise<T> { | ||
| return new Promise((resolve) => { | ||
| setTimeout(async () => { | ||
| const result = await request(); | ||
| resolve(result); | ||
| }, 1000 / API_RATE_LIMIT); | ||
| }); | ||
| } |
There was a problem hiding this comment.
Handle errors in rateLimitedRequest to prevent unhandled rejections
If the request() throws an error, the promise may neither resolve nor reject, leading to unhandled promise rejections. It's important to handle exceptions within the promise.
Wrap the request() call in a try-catch block and reject the promise on error.
Apply this diff to handle errors appropriately:
private async rateLimitedRequest<T>(request: () => Promise<T>): Promise<T> {
return new Promise((resolve, reject) => {
setTimeout(async () => {
+ try {
const result = await request();
resolve(result);
+ } catch (error) {
+ reject(error);
+ }
}, 1000 / API_RATE_LIMIT);
});
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private async rateLimitedRequest<T>(request: () => Promise<T>): Promise<T> { | |
| return new Promise((resolve) => { | |
| setTimeout(async () => { | |
| const result = await request(); | |
| resolve(result); | |
| }, 1000 / API_RATE_LIMIT); | |
| }); | |
| } | |
| private async rateLimitedRequest<T>(request: () => Promise<T>): Promise<T> { | |
| return new Promise((resolve, reject) => { | |
| setTimeout(async () => { | |
| try { | |
| const result = await request(); | |
| resolve(result); | |
| } catch (error) { | |
| reject(error); | |
| } | |
| }, 1000 / API_RATE_LIMIT); | |
| }); | |
| } |
Security
Changes Detected
|
Summary by CodeRabbit
New Features
FileServiceandGoogleDriveServicewith new integrations for improved data handling.Bug Fixes
Documentation